Fixes #712.

Problem

The Variant metadata header's offset_size_minus_one field lives in bits 6-7, but VariantBinary read it from bits 5-6 (METADATA_OFFSET_SIZE_SHIFT = 5). Every existing fixture uses offset_size = 1, where both readings yield 0, so the bug was invisible across the whole suite (125 byte-exact shredded-variant cases + the comparison sweep). Any Variant whose dictionary string section exceeds 255 bytes — needing offset_size >= 2 — was misparsed into garbage.

It surfaced via the negative_dictionary_size fixture from apache/parquet-testing#113, which uses offset_size = 4.

Fix

• METADATA_OFFSET_SIZE_SHIFT 5 → 6 (+ corrected the layout comment).
• Guard against a 4-byte dictionary_size that reads back as a negative int: reject with a clear "not a valid unsigned int" message rather than letting the bogus size drive later arithmetic. (The (dictSize+1)*offsetSize overflow widening is intentionally left to Unguarded 32-bit overflow in Variant object/array offset arithmetic #713 to avoid overlap.)

Tests

• Real end-to-end fixture via tools/simple-datagen.py: variant_metadata_offset_size2.parquet — a VARIANT object whose metadata dictionary is 320 bytes, forcing offset_size = 2. VariantLogicalTypeTest.readsVariantWhoseMetadataUsesOffsetSizeTwo reads it through the VARIANT row API and resolves both long-named fields ('a'*160 → INT8 5, 'b'*160 → BOOLEAN_TRUE).
• VariantMetadataTest.negativeDictionarySizeRejected for the guard.
• Both new tests fail against the pre-fix shift (verified) and pass with the fix.
• No regressions: the 125 shredded-variant byte-exact tests plus the variant decoder/encoder, row-API, and conversion tests are green.

Notes

• Change is confined to internal packages — no public API or config change, so no usage-docs update.
• Release notes are curated at release time off the 1.0.1.Final milestone (where Variant metadata offset-size read off by one bit (bits 6-7, not 5-6) #712 lives), so none added here.